Expeditor Server 6.2.1 provides a new symbol, "!()", to represent the "not in" concept. This symbold filters clients that are not in the () clause. The symbol "!()" supports the (FilterInterface.FilterType_Client) client type with the inventory prefixes "feature.", "plugin.", "property.", "preference.", "systemproperty.",  "clientFile.", "clientProp." and "customNode.". If the symbol ! is used for unsupported types, or client types with unsupported prefixes in the filter edit, it returns as invalid. The symbol ! must be put in front of and contain "(...)".

In the client management task view, administrators can now copy existing tasks and submit them to new target clients. The task options, such as scheduling information, can be edited. This allows administrators to save their effort when submitting tasks from scratch.

Filters can be used to target tasks and view clients. A filter must be synchronized in order for the client to get tasks assigned to that filter. Currently, a filter is synchronized when it is created, and then only periodically afterwards according to the filter sync interval. The reason behind this is to allow the administrator to control expensive LDAP look-ups and database queries. When a client initially enrolls, it does not become a target to tasks associated with a filter until the filter synchronizes, and the client again connects. This causes a delay in the client getting the tasks. Enabling real-time filtering in server settings would force a synchronization each time a new client enrolls. The potential performance impact will be brought up for each enrollment's individual LDAP look-up.

When submitting a chained task, users can now designate a subtask as a permanent task. The next time the user wants to create a chained task, the permanent task can be re-used. The administrator can also utilize this function to designate several frequently used sub-tasks.

Custom commands have been implemented by adding Custom Nodes as a new inventory collection type. Each custom node will have a path in the SyncML tree. Administrators can create custom node collection definitions that include the node path and sub node depth in advance. Once the inventory collection task is submitted, the client's previously defined SyncML tree can be retrieved by the server. In addition, the custom node can be added, edited, or deleted on the administration console and a task will be submitted accordingly to update the target clients.

When administrators define a new custom node, they have the option of specifying a sub-node depth. If this value is greater than 0, when the inventory task is run it will attempt to recursively retrieve the node for the depth specified and return all the nodes defined underneath.

Client properties are name/value pairs that are associated with clients on the server. They can also be used in filters. In Expeditor 6.2 a user could add their own customized properties using the web services API. In this release, they can view and edit each client's properties using the console.